A Component Library in Figma is a centralized collection of reusable components that designers can use across multiple screens, pages, projects, and product experiences. Components can include buttons, inputs, cards, navigation elements, modals, icons, forms, menus, and other reusable UI patterns.
Component Libraries help design teams maintain consistency, reduce repetitive work, improve scalability, and create a shared source of truth for interface design. Instead of recreating the same UI element repeatedly, designers can create a main component once and reuse instances of it throughout their designs.
In Figma, a component library can also be published so that reusable components, styles, and variables can be made available to other files. When published assets are updated in the source library, users of the library can review available updates and apply them to their files.
Learn professional Figma design through JustAcademy Figma Training and explore the Register for Figma Course Demo.
A Component Library is a structured collection of reusable Figma components that can be inserted into different design files. It acts as a shared repository of approved interface elements.
Component Library = A centralized collection of reusable UI components that can be shared, organized, maintained, and reused across multiple Figma files.
A component is a reusable UI element that can be instantiated multiple times in a design. The main component defines the source design, while instances are reusable copies that remain connected to the main component.
Main Component
↓
Component Instance
↓
Reusable UI
↓
Multiple Screens
The main component is the source component that defines the structure, appearance, properties, and behavior of reusable instances. Changes to the main component can be published through a library so connected instances can receive available updates.
An instance is a reusable copy of a component. It maintains a connection to its main component and can inherit changes while allowing supported customizations.
| Main Component | Instance |
|---|---|
| Source component | Reusable copy |
| Defines component structure | Uses the defined structure |
| Used to create instances | Used inside product designs |
| Can be published through a library | Can receive available library updates |
A well-managed component library provides approved versions of commonly used interface elements. Designers can use these components instead of creating separate versions that may become inconsistent over time.
Design System
↓
Component Library
↓
Approved Components
↓
Design Files
↓
Product Screens
↓
Consistent User Experience
| Component | Examples |
|---|---|
| Buttons | Primary, Secondary, Tertiary |
| Inputs | Text, Search, Password |
| Navigation | Navbar, Sidebar, Tabs |
| Cards | Product, Profile, Content |
| Dialogs | Modal, Confirmation, Alert |
| Forms | Checkbox, Radio, Select |
| Feedback | Toast, Banner, Tooltip |
| Icons | Search, Close, Menu, Profile |
Component Library
├── Foundations
│ ├── Colors
│ ├── Typography
│ ├── Spacing
│ └── Effects
├── Components
│ ├── Buttons
│ ├── Inputs
│ ├── Cards
│ ├── Navigation
│ └── Modals
├── Patterns
│ ├── Forms
│ ├── Tables
│ └── Search
└── Documentation
Local components are components created inside the current Figma file. They can be reused within that file without publishing the file as a library.
Published components are components made available through a Figma library so they can be used in other files. Publishing turns reusable assets into shared resources for designers who have access to the library.
| Local Component | Published Component |
|---|---|
| Available in the current file | Available through a library |
| Useful for individual projects | Useful for teams and products |
| No library publishing required | Requires publishing for cross-file distribution |
| Limited to its file | Can be consumed by other enabled files |
To create a component, design the required UI element, select the relevant layer or frame, and convert it into a component. The resulting component can then be reused through instances.
Create UI Element
↓
Select Frame or Layers
↓
Create Component
↓
Define Properties
↓
Create Instances
↓
Reuse Across Screens
The common keyboard shortcut for creating a component is Ctrl + Alt + K on Windows and Option + Command + K on macOS.
Component names should be clear, predictable, and consistent. A good naming structure makes components easier to locate in the Assets panel and easier for other designers to understand.
Figma supports slash-separated naming patterns that can help organize related components in the Assets panel.
Button/Primary
Button/Secondary
Button/Danger
Input/Text
Input/Search
Icon/Close
Icon/Profile
Card/Product
| Category | Components |
|---|---|
| Actions | Buttons, Icon Buttons |
| Forms | Inputs, Checkbox, Radio |
| Navigation | Tabs, Navbar, Sidebar |
| Content | Cards, Lists, Tables |
| Feedback | Alerts, Toasts, Tooltips |
| Overlays | Modal, Dialog, Drawer |
A component set groups related component variants into a structured collection. For example, different button configurations can be represented as variants within one button component set.
Variants allow related versions of a component to be managed together. Instead of creating completely unrelated components for every state, designers can create a component set with properties such as type, size, and state.
Button
├── Type: Primary
│ ├── State: Default
│ ├── State: Hover
│ └── State: Disabled
├── Type: Secondary
│ ├── State: Default
│ ├── State: Hover
│ └── State: Disabled
└── Type: Danger
├── State: Default
├── State: Hover
└── State: Disabled
Component properties allow designers to expose meaningful controls for instances. Properties can control text, visibility, instance swaps, and variant selections.
Boolean properties allow designers to show or hide optional parts of a component.
Show Icon = True
Show Icon = False
Show Badge = True
Show Badge = False
Text properties allow reusable components to expose editable text values while keeping the component structure consistent.
Button Label = "Buy Now"
Button Label = "Learn More"
Button Label = "Submit"
Instance swap properties allow designers to replace nested component instances with another approved component while keeping the surrounding structure intact.
Variant properties allow designers to switch between defined component configurations such as size, type, state, and theme.
Nested components are components placed inside another component. For example, a button may contain an icon component, while a card may contain an avatar, badge, and action button.
Card
├── Image
├── Avatar
├── Title
├── Description
├── Badge
└── Button
Component anatomy describes the internal structure and parts that make up a component.
Button
┌───────────────────────────┐
│ Icon Label Arrow │
└───────────────────────────┘
↑ ↑ ↑
Icon Text Optional
Interactive components commonly require multiple states such as default, hover, pressed, focus, disabled, loading, and selected.
| State | Purpose |
|---|---|
| Default | Normal component appearance |
| Hover | Pointer interaction state |
| Pressed | Active interaction state |
| Focus | Keyboard or accessibility focus |
| Disabled | Unavailable interaction |
| Loading | Processing state |
| Selected | Chosen or active state |
Button
├── Primary
├── Secondary
├── Tertiary
├── Destructive
├── Icon Only
└── Link
States
├── Default
├── Hover
├── Pressed
├── Focus
├── Disabled
└── Loading
Input
├── Default
├── Focus
├── Filled
├── Error
├── Success
├── Disabled
└── Read Only
Card
├── Product
├── Profile
├── Article
├── Pricing
└── Feature
Auto Layout is essential when building flexible component libraries. It allows components to respond to content changes while maintaining consistent padding, gaps, alignment, and resizing behavior.
Component padding defines the internal space between the component boundary and its content. Consistent padding makes similar components feel visually related.
Button
┌──────────────────────────────┐
│ 16px Icon 8px Label 16px │
└──────────────────────────────┘
Gap controls the space between child elements inside an Auto Layout component.
Icon
↓
8px
↓
Label
Hug contents allows a component or child layer to resize according to its content. This is especially useful for buttons, labels, badges, and cards.
Fill container allows a child layer to use the available space provided by its parent. It is useful for responsive components and flexible layouts.
Fixed sizing keeps a layer at a defined dimension. It can be useful when a component requires a controlled width or height.
Responsive components are designed to adapt to different content lengths, screen sizes, and container dimensions without breaking their visual structure.
Component libraries work closely with design tokens such as colors, typography, spacing, radii, and shadows. Tokens provide foundational values while components apply those values to reusable UI structures.
Design Tokens
├── Colors
├── Typography
├── Spacing
├── Radius
└── Effects
↓
Components
↓
Patterns
↓
Screens
Components can use reusable color styles or variables so that colors remain consistent across the library.
Typography styles can be applied consistently to component labels, headings, descriptions, and supporting text.
Spacing systems help standardize component padding, gaps, section spacing, and relationships between nested elements.
Effects such as shadows and blurs can be standardized and reused across components to maintain visual consistency.
Foundations
↓
Tokens
↓
Primitive Components
↓
Composite Components
↓
Patterns
↓
Templates
↓
Screens
Primitive components are simple reusable building blocks such as icons, buttons, inputs, badges, and basic controls.
Composite components combine multiple primitives into more complex UI elements such as search bars, product cards, navigation menus, and form groups.
Patterns are reusable combinations of components designed to solve common interface problems, such as checkout forms, search experiences, login forms, and filtering interfaces.
Templates combine patterns and components into larger page structures. They help teams create consistent layouts while allowing content to vary.
| Component Library | Design System |
|---|---|
| Focuses strongly on reusable UI components | Covers broader design principles |
| Contains components and variants | Contains components, tokens, guidelines, patterns, and documentation |
| Helps create consistent UI | Defines how the product should be designed |
A UI kit is generally a collection of ready-made design elements for use in a design project. A mature component library is usually more structured, governed, documented, and maintained as part of an ongoing design system.
Copy-paste creates independent duplicates, while component instances maintain a relationship with their source component. Libraries therefore provide stronger consistency and easier maintenance.
Audit Existing UI
↓
Identify Reusable Elements
↓
Define Foundations
↓
Create Components
↓
Add Variants
↓
Add Properties
↓
Document Components
↓
Review
↓
Publish Library
↓
Team Uses Instances
↓
Publish Updates
↓
Maintain Library
A dedicated library file can contain reusable components, styles, variables, documentation, and supporting design-system assets that a team wants to distribute.
Pages can be organized by purpose so designers can quickly locate foundations, components, patterns, documentation, and archived elements.
Pages
├── Cover
├── Foundations
├── Buttons
├── Forms
├── Navigation
├── Cards
├── Feedback
├── Overlays
├── Patterns
├── Documentation
└── Archive
Every important component should have documentation explaining its purpose, anatomy, properties, states, usage, and limitations.
A component description should explain what the component is designed for and when it should be used. Clear descriptions make libraries easier to consume.
Component: Button/Primary
Purpose:
Used for the primary action on a screen.
Use when:
There is one main action.
Avoid when:
The action is secondary or destructive.
States:
Default, Hover, Pressed, Focus, Disabled
Button/Primary
Button/Secondary
Button/Danger
Input/Text
Input/Search
Modal/Confirmation
Card/Product
Button New
Button Final
Button Final 2
Test Button
Copy of Button
New Input
Variant properties should describe meaningful differences rather than implementation details.
Type = Primary
Size = Medium
State = Default
Icon = True
Well-organized names and file structures make components easier to find in the Assets panel. Designers can search and browse components from enabled libraries.
To use a published component, enable the required library, open the Assets panel, locate the component, and insert it onto the canvas to create an instance.
Enable Library
↓
Open Assets
↓
Find Component
↓
Insert Component
↓
Create Instance
↓
Customize Allowed Properties
Libraries need to be available to a file before their published assets can be consumed. Library controls allow designers to enable the libraries they need.
A library can contain components, styles, and variables. These assets can work together as part of a broader design system.
After creating components, styles, or variables in a source file, the file can be published as a library. The publishing workflow allows the publisher to review changes and add useful information before publishing.
Create Components
↓
Review Components
↓
Open Assets
↓
Open Libraries
↓
Publish Current File
↓
Review Changes
↓
Add Description
↓
Publish
When a published component changes in the source library, the changes first exist in the source file. They need to be published before users of the library can receive the updated version.
Files using a published library can receive notifications when updates are available. Designers can review the changes and decide whether to accept them.
Versioning helps teams manage changes to components over time. Significant changes should be documented so designers and developers understand what changed and why.
A breaking component change can significantly alter structure, behavior, properties, or visual appearance. Such changes should be reviewed carefully before being published to a shared library.
Non-breaking changes improve a component without invalidating its intended usage. Examples can include minor visual refinements, spacing improvements, or documentation updates.
When a component is replaced by a newer version, the old component should be clearly marked as deprecated and a recommended replacement should be documented.
Migration means moving existing designs from an older component to its newer replacement while preserving the intended user experience.
Governance defines who can create, review, publish, modify, deprecate, and maintain components. Strong governance prevents uncontrolled growth of a component library.
Designer Creates Component
↓
Design Review
↓
Accessibility Review
↓
Naming Review
↓
Developer Review
↓
Library Approval
↓
Publish
Component libraries should consider accessibility from the beginning. Components should support clear focus states, readable typography, sufficient contrast, appropriate touch targets, and meaningful interaction states.
Button
├── Default
├── Hover
├── Focus
├── Pressed
├── Disabled
└── Loading
Accessibility
├── Clear label
├── Visible focus
├── Adequate contrast
└── Appropriate target size
Components should work across different screen sizes and containers. Auto Layout, responsive resizing, constraints, and flexible content help components adapt to mobile, tablet, and desktop layouts.
A mobile component library may include bottom navigation, mobile headers, cards, mobile forms, buttons, sheets, dialogs, and touch-friendly controls.
A desktop component library may include navigation bars, sidebars, data tables, dashboards, filters, menus, desktop dialogs, and multi-column layouts.
Organizations supporting web, mobile, and other platforms may maintain shared foundations while allowing platform-specific components where interaction patterns differ.
A well-documented component library improves communication between designers and developers. Clear component names, states, properties, and usage rules help developers understand intended implementation.
Figma design components represent reusable design elements. Developers implement corresponding UI components in code using frameworks or technologies appropriate to the product.
Figma Component
↓
Design Specification
↓
Developer Handoff
↓
Code Component
↓
Product UI
| Figma Concept | Common CSS Concept |
|---|---|
| Auto Layout | Flexbox/Grid |
| Gap | gap |
| Padding | padding |
| Fill Container | Flexible sizing |
| Hug Contents | Content-based sizing |
| Color Variable | CSS custom property |
| Text Style | Typography rules |
Tokens
├── Color
├── Typography
├── Spacing
├── Radius
└── Shadow
↓
Components
├── Button
├── Input
├── Card
└── Modal
↓
Patterns
↓
Screens
Variables can provide reusable values for colors, spacing, dimensions, and other supported properties. Using variables alongside components can make a design system easier to scale and maintain.
Components can be designed to work with themed variables so that the same component structure can support different visual modes.
Button
↓
Color Variables
↓
Light Mode
↓
Dark Mode
An e-commerce component library may contain product cards, pricing elements, cart controls, filters, search bars, navigation, ratings, badges, checkout forms, and payment UI patterns.
E-Commerce Library
├── Navigation
├── Product
│ ├── Product Card
│ ├── Product Image
│ ├── Price
│ └── Rating
├── Shopping
│ ├── Cart Item
│ └── Quantity Selector
├── Forms
└── Checkout
A dashboard library can contain metric cards, charts, tables, filters, tabs, sidebars, pagination, alerts, and form controls.
A banking library can contain account cards, transaction rows, balance summaries, transfer forms, security controls, navigation, notifications, and confirmation dialogs.
Create a button component set containing primary, secondary, tertiary, destructive, icon-only, and loading variations. Add properties for size, state, icon visibility, and label.
Button
├── Type
│ ├── Primary
│ ├── Secondary
│ └── Destructive
├── Size
│ ├── Small
│ ├── Medium
│ └── Large
├── State
│ ├── Default
│ ├── Hover
│ ├── Focus
│ ├── Pressed
│ └── Disabled
└── Icon
├── None
├── Leading
└── Trailing
Create reusable input, select, checkbox, radio, textarea, helper-text, validation, and form-section components.
Create product, profile, article, pricing, and feature cards using shared spacing, typography, color, image, and action components.
Create desktop navigation, mobile navigation, sidebar, tabs, breadcrumbs, pagination, and menu components.
Build a complete library containing foundations, variables, styles, icons, components, patterns, documentation, and examples.
Complete Library
├── Foundations
├── Variables
├── Styles
├── Icons
├── Components
├── Patterns
├── Templates
├── Documentation
└── Archive
A component playground is a dedicated area where designers can review component variants, properties, states, and combinations before using them in production screens.
COMPONENT: BUTTON
Purpose
Usage
Anatomy
Variants
Properties
States
Spacing
Accessibility
Do
Don't
Examples
Changelog
| Do | Don't |
|---|---|
| Use approved components | Recreate components unnecessarily |
| Use defined variants | Create random variations |
| Follow spacing rules | Use arbitrary spacing |
| Use semantic names | Use temporary names |
| Review library updates | Ignore important updates |
A component library should be regularly reviewed for duplicate components, outdated variants, unused elements, naming inconsistencies, accessibility problems, and broken documentation.
Governance should define ownership, review responsibilities, publishing permissions, naming conventions, versioning practices, contribution rules, and deprecation processes.
Assigning ownership helps ensure that components have someone responsible for reviewing issues, maintaining documentation, and approving changes.
Designer Identifies Need
↓
Create Component
↓
Document Component
↓
Peer Review
↓
System Review
↓
Approval
↓
Publish
↓
Team Adoption
Edit Main Component
↓
Review Change
↓
Publish Update
↓
Library Notification
↓
Designer Reviews Update
↓
Accept Update
↓
Instances Use Updated Component
Published components can be moved between library files in supported workflows, but the process should be handled carefully to preserve component relationships and avoid disrupting existing instances.
For organizations using supported Figma plans and features, library analytics can help teams understand component usage and identify opportunities for improvement.
| Concept | Meaning |
|---|---|
| Component | Reusable UI element |
| Main Component | Source component that defines reusable design |
| Instance | Reusable copy connected to a component |
| Component Set | Collection of related variants |
| Variant | Defined version of a component |
| Component Property | Control exposed by a component |
| Library | Published collection of reusable assets |
| Design System | Broader system of foundations, components, patterns, and rules |
| Auto Layout | Flexible layout system used to build responsive components |
Analyze Existing Product
↓
Identify Reusable UI
↓
Define Foundations
↓
Create Components
↓
Configure Auto Layout
↓
Create Variants
↓
Add Component Properties
↓
Create Documentation
↓
Review Accessibility
↓
Review Naming
↓
Publish Library
↓
Enable Library
↓
Use Instances
↓
Review Updates
↓
Maintain and Govern Library
Component Libraries in Figma provide a structured way to create, organize, reuse, share, and maintain UI components across products and design files. They reduce duplication while helping teams maintain a consistent visual and interaction language.
A strong component library combines reusable components with variants, component properties, Auto Layout, design tokens, variables, styles, documentation, accessibility rules, and clear naming conventions. Publishing the library allows approved components to be consumed across files, while controlled updates help teams keep their designs aligned.
For professional product design, a component library should not simply be a collection of visual elements. It should be a maintained system with clear ownership, documentation, governance, review processes, and a predictable workflow from component creation to team adoption.
To learn more about professional Figma design and component-library workflows, visit JustAcademy Figma Training or Register for Figma Course Demo.
